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REMARKS 

Claims 1-16 remain in the Application. No claim has been allowed. 

Claims 7 and 8 were objected to because of various informalities. It is believed that with 
entry of the forgoing amendments, these claims are now in condition for allowance. 

Claims 1, 5-9, and 11-14, and 16 were rejected under 35 U.S.C. 103(a) as supposedly 
being unpatentable over Kadansky (U.S. 6,507,562) in view of Dillon (U.S. 2003/0206554). 

In particular, the Examiner argues that Kadansky teaches notification (by transmitting an 
alert beacon message) at a plurality of end node devices of a scheduled bulk data transmission (at 
column 6, lines 30-37), and he is correct to that extent. However, the Examiner is incorrect in 
concluding that Kadansky also teaches notification including information indicating an expected 
end time. Kadansky only suggests identification by the sequence number of the last data packet. 
(See Kadansky at column 15, lines 7-10 and column 33, lines 48-56.) 

We respectively submit that notification of a packet sequence number is not the same 
thing as notification of a broadcast an end time . In fact, the Kadansky prior art technique of 
notification by sequence or number contains several severe deficiencies to which Applicants' 
invention provides a solution. 

First of all, we respectfiilly request the Examiner to note that the Applicants' definition of 
"end time". In the Applicants' claims, this is a reference to a particular date and time. It is clear 
firom Applicants' specification that a multicast start time is expressed in Universal Time Code 
(UTC) notations such as a date and time of day, and a multicast duration in milliseconds (See 
Fig. 2.) This permits the calculation of a package end (expire) time in Fig. 3 A. It is not a 
reference to a data packet. 
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The Applicants' invention of using an expected end time is different from and contains 
advantages over a mere indication of the last packet index number, for at least two reasons. First, 
in bulk data transmissions, such as might use the UDP protocol, packets may arrive in any order. 
Thus, the arrival of a last packet may not indicate that all expected data has actually been 
received. 

Furthermore, and perhaps more importantly, consider what occurs if there is a failure of 
the physical link between the transmitter and receiver. In this instance, the receiver will start 
receiving content, but will continue to look for a last packet. However, such last packet will 
never arrive; the receiver will never know when the end of transmission should have occurred. 
With Applicants' expected end time approach, at least one error can be detected more readily. 

Kadansky at column 32, lines 54-59, as referred to by the Examiner or anywhere else for 
that matter, has no mention of, and does not teach using a specified end time. 

Therefore, both Applicants' claim steps of (a) notifying the plurality of end node devices 
of an expected end time for the scheduled transmission, as well as (b) at the expected end time. 
determining if the bulk data content was received as expected, are not found in the Kadansky 
prior art. 

Dillon also does not provide these missing claimed features of Applicants' invention. 

In order for an invention to be considered obvious, each element of the claim must be 
found in the prior art. Claim 1 therefore is not obvious or anticipated by either Dillon or 
Kadansky and should be allowable. 

As to the rejection of claim 5, Kadansky does not teach notifying end node devices of an 
expected start time or duration information; it merely contains an indication of a packet number. 
The statement in Kadansky at column 32, lines 54-59 is merely a reference to a simulation 
experiment in which 1000 packets were sent, each 1400 bytes long. In that experiment it was 
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said that the sending starts at 1.5 seconds from the beginning of the simulation. Thus, even here 
Kadanskv is not suggesting that an expected duration or end time be included in a message. 

And column 15, lines 7-12 of Kadansky teaches that a sender notifies all members of a 
session when it has completed data transmission, by transmitting a beacon packet that includes 
the sequence number of the last data packet transmitted. At column 33, lines 48-56, it is said is 
that end of transmission is signaled to the multicast group with a beacon packet that has the 
"TXdone flag" set; and that packet also indicates the sequence number of the last data packet 
sent. 

But, there is no mention suggestion or other teaching that start time of the bulk data 
transmission and the expected maximum transmission time are included as part of a notification 
to the receivers prior to transmitting the bulk data content via broadcast, as set forth in 
Applicants' claims. 

Claims 2, 3 and 15 were also rejected as being unpatentable over Kadansky in view of 
Dillon; and additionally and further in view of Gupta, U.S. Patent 6,577,599. As has been 
explained above, neither Kadansky nor Dillon teach the claimed step of determining an expected 
end time for the selected transmission, and thus cannot be considered to provide all of 
Applicants* claimed features. Neither does Gupta. These claims are also allowable. 

Claim 4 was fiirther rejected in view of Kadansky, Dillon and McNeil. McNeil also does 
not supply the novel elements of Applicants' claim. In particular, McNeil has no teaching of 
notifying a plurality of end node devices of a scheduled bulk data transmission including 
information that can be used to determine an expected end time. Thus, claim 4 is likewise 
allowable. 
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CONCLUSION 

In view of the above amendments and remarks, it is believed that all claims are in 
condition for allowance, and it is respectfully requested that the application be passed to issue. If 
the Examiner feels that a telephone conference would expedite prosecution of this case, the 
Examiner is invited to call the undersigned. 



Respectfully submitted, 

HAMILTON, BROOK, SMITH & REYNOLDS, P.C. 




David J. Thibodeau, Jr. 
Registration No. 31,671 
Telephone: (978) 341-0036 
Facsunile: (978)341-0136 



Concord, MA 01742-9133 



